In recent years, the environment surrounding business information systems has greatly changed along with the rapid advances in internet technology as represented by the WWW (World Wide Web). In particular, recently, cooperation over a wide range exceeding that common hitherto has begun in the form of cooperation with business internal systems, group businesses and other businesses, and cooperation with general consumers aimed at improving customer service and improving the efficiency of business activity.
In a business information system supporting business activity, a rapid response to the aforementioned extreme changes in the business environment is desired. In this case, when adopting a technique for carrying out the complete reconstruction of a business information system, because of the barriers of development time and cost, it is difficult to respond quickly to extreme environmental changes. Therefore, in order to respond to extreme environmental changes, it is necessary to add items necessary to the new objectives as the occasion demands, while making effective use of existing assets. It is also necessary to select the optimum materials (vendor, hardware, software) at any particular time and for the existing system and the new system to have a common basis.
In order to obtain this common base, it is vital for the materials of the existing system and the materials of the new system to work in cooperation with each other without being conscious of any differences between them. Moreover, in the field of network computing, new technologies are being developed continuously and it is necessary that these new technologies can be dealt with flexibly. Because of this background, recently, attention has been focused on object-oriented technologies such as CORBA and the like which is a standard for distributed system architecture as a common basis for achieving cooperation between various computing environments.
CORBA is a standardized specification for connection between different varieties of equipment determined by a standardization OMG (Object Management Group), and regulates various types of API (Application Program Interface) for distributed application architecture and cooperation protocols between different varieties of equipment. Simply put, CORBA is a standard technology for providing a mechanism for a client to access an object (for example, an application program) in a server in a distributed system environment. In this case, the term object in CORBA means an entity identifiably encapsulated for providing either one or a plurality of services that can be requested by a client.
FIG. 12 is a block diagram showing a structural example 1 of a conventional object reference generating system that uses CORBA. In this diagram, business servers 10 and 20 are separately provided so as to distribute the load in response to accesses from a client 51 and a client 52 and provide the same service to the client 51 and the client 52. The business server 10 is connected to a network 30 and provides the object 11 (for example, an application program) to the clients 51 and 52. The TCT/IP (Transmission Control Protocol/Internet Protocol) IP address IP1 is allocated to the business server 10.
A naming service section 12 provides a naming service in CORBA to the clients 51 and 52, and has the function of controlling the object 11 by name. By using this naming service, when the clients 51 and 52 access the object 11, the access is possible using the name and not the position of the object 11, therefore it is not necessary to be conscious of the physical position of the object 11.
Specifically, when access is made by the client 51 (or the client 52), the naming service 12 generates an object reference and returns this to the client 51 (or client 52) thus providing a naming service. This object reference is information for uniformly identifying objects by name and has the format F shown in FIG. 13.
As is shown in FIG. 13, the object reference is constructed from information consisting of “IOR (Interoperable Object Reference) header”, “ID” (IDentification), “host name” (IP address), “PORT number”, “object key”, “tag component”, and “other profile”. IOR header is header information for the object reference. ID is an identifier for identifying the object reference.
Host name (IP address) is the name of the host having the object, specifically, the IP address of the server. PORT number is the port number for specifying an object within the server. Object key is information for uniformly specifying objects within a server. Returning to FIG. 12, the ORB (Object Request Broker: a mechanism for communicating between distributed objects) 13 is a software bus for acting as an intermediary between the business server 10 and the clients 51 and 52. The ORB 13 has an initial object reference that includes its own IP address and PORT number.
The business server 20 cooperates with the business server 10 to distribute the load and is connected to the network 30. The structure of the business server 20 is the same as that of the business server 10. Namely, each of the object 21, the naming service section 22, and the ORB 23 in the business server 20 is provided with the same functions as the object 11, the naming service section 12, and the ORB 13 in the business server 10. The IP address IP2 is allocated to the business server 20.
The apportioning server 40 is designed to achieve a load distribution and is interposed between the network 30 and the network 50. The apportioning server 40 has a supervisory function of supervising the respective loads on the business server 10 and the business server 20, as well as an apportioning function of apportioning accesses from the client 51 (or the client 52) to the server with the lighter load out of the business server 10 and the business server 20. The IP address IP3 is allocated to the apportioning server 40. The client 51 and the client 52 are connected to the network 50 and access the business server 10 or the business server 20 through the network 50, the apportioning server 40, and the network 30.
In the above structure, when there is an access request from the client 51, the access from the client 51 is apportioned by the apportioning server 40, for example, to the business server 10, which has a lighter load than the business server 20. As a result, the client 51 establishes a connection with the business server 10 after acquiring the ORB 13 object reference.
Next, the client 51 requests an object reference of the naming service section 12 from the naming service section 12. As a result, the naming service section 12 generates an object reference including at least the “host name” (IP address)=IP address IP1 and the “PORT number” shown in FIG. 13, and notifies this to the client 51. The IP address in the object reference of the naming service section 12 is always IP address IP1.
After receiving the object reference of the naming service section 12, the client 51 acquires the IP address IP1 and the PORT number of the naming service section 12 and then establishes a connection with the naming service section 12. Next, the client 51 requests an object reference of the object 11 using this connection. When this object reference is received, the client 51 acquires the IP address IP and the PORT number from the object reference and establishes a connection with the object reference 11. Thereafter, the client 51 receives distributions of the object 11 using this connection.
FIG. 14 is a block diagram showing a structural example 2 of a conventional object reference generating system that uses CORBA. This diagram shows an object reference generating system provided with: a single business server 60; a first group network 70 and a second group network 80 that are independent of each other; clients 711 to 71n who are connected to the first group network 70 and form the first group; and clients 811 to 81n who are connected to the second group network 80 and form the second group.
In this diagram, the business server 60 provides service to the clients 711 to 71n and the clients 811 to 81n and is connected to both the first group network 70 and the second group network 80. The IP address IP4 and the IP address IP5 are both allocated to the business server 60. The IP address IP4 corresponds to the first group network 70 and the IP address IP5 corresponds to the second group network 80.
The structure of the business server 60 is the same as that of the business server 10 (see FIG. 12). Namely, the object 61, the naming service section 62, and the ORB 63 of the business server 60 are provided with the same functions as the object 11, the naming service section 12, and the ORB 13 shown in FIG. 12.
In the above structure, a client 711 accesses the IP address IP4 via the first group network 70. As a result, after acquiring the object reference of the ORB 63, the client 711 established a connection with the business server 60. Next, the client 711 requests an object reference of the naming service section 62 from the naming service section 62. As a result, the naming service section 62 generates an object reference including at least the “host name” (IP address)=IP address IP4 and the PORT number shown in FIG. 13, and notifies this to the client 711. The IP address in the object reference of the naming service section 62 is IP address IP4.
After receiving the object reference of the naming service section 62, the client 711 acquires the IP address IP4 and the PORT number of the naming service section 62 and then establishes a connection with the naming service section 62. Next, the client 711 requests an object reference of the object 61 using this connection. When this object reference is received, the client 711 acquires the IP address IP4 and the PORT number from the object reference and establishes a connection with the object reference 61. Thereafter, the client 711 receives distributions of the object 61 using this connection.
As described above, an example of load distribution was described in FIG. 12, however, in actual fact, in a conventional object reference generating system, the problem has existed that it has not been possible to distribute the load. Namely, in order to achieve load distribution, the client 51 needs to access the IP address IP3 of the apportioning server 40.
However, because the IP address of the object reference generated in the naming service section 12 is IP address IP1 and not IP address IP3 for load distribution, the apportioning server 40 is not able to distribute the load. Accordingly, conventionally, the problems have existed that not only has it not been possible to increase reliability by load distribution, but also it has not been possible to provide a naming service in CORBA in a load distributed environment.
Moreover, in FIG. 14, an example was described in which there were provided a business server 60 having an IP address IP4 and an IP address IP5 and a first group network 70 and a second group network 80 which were both independent of each other. However, in actual fact, in a conventional object reference generating system, there are cases when the clients 711 to 71n and the clients 811 to 81n are not able to receive the services of the naming service.
Namely, when an access is made from any one of the clients 711 to 71n and when the IP address of the object reference generated in the naming service section 62 is IP address IP4, the client is able to establish a connection with the object 61 through the first group network 70 and the IP address IP4.
However, when an access is made from any one of the clients 711 to 71n, and when the IP address of the object reference generated in the naming service section 62 is the other IP address IP5, the problem arises that, because the first group network 70 does not correspond to the IP address IP5, the client is not able to establish a connection with the object 61.